I can't say I'm happy that we're going to require dart to be on the user's PATH here as this will break or could cause unexpected behavior for those running bin/webdev.dart from source without dart on their path. However, I don't think there's a good way around it and this will have no impact on most users who aren't developing in the Dart SDK and webdev. This also won't be a problem once we move webdev functionality into the Dart CLI.

Thanks @natebiggs! 🙏

I guess we could check if we're running in JIT mode, and then prefer using the SDK we're running from. But we probably shouldn't.

dart install being self-contained executable bundles leads to a question which Dart SDK should be used for any CLI tool that wants to use an SDK. I think using the one on PATH is the right thing to do. (E.g. it's what clang or linker you'd use as well.) I believe trying to dart compile aot-snapshot and then Isolate.spawnUri is not something one should be doing with a dart installed tool.

This is definitely a departure from dart pub global activates reliance on the Dart SDK. I believe this is a feature.

CLI tools that rely on the specific Dart SDK version should (1) be bundled with the Dart SDK, or (2) be run in JIT mode. (That's my thinking right now. Happy to be proven wrong with a valid use case.)

break or could cause unexpected behavior for those running bin/webdev.dart from source without dart on their path

I suspect there are very few if any people using this in real workflows. And I don't mind pushing them away from that workflow either. Encouraging folks to an established workflow is probably better.

If we get any pushback from this I wouldn't mind adding a flag to webdev itself that allows users to specify an SDK path that we'll use for subprocesses. If anyone really needs to run against a specific SDK that seems like a more sustainable/explicit approach than requiring that they run from that specific executable.